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Abstract. As urban populations and traffic congestion levels increase, effective use of information and 
communication tools and intelligent transportation systems as becoming increasingly important in order to 
maximize the efficiency of transportation networks. The appropriate placement and employment of these 
tools within a network is critical to their effectiveness. This presentation proposes and demonstrates the 
use of a commercial transportation simulation tool to simulate dynamic traffic assignment and rerouting to 
model route modifications as a result of traffic information. 


1. INTRODUCTION 

Modeling and Simulation (M&S) of transportation 
is critical to developing and assessing proposed 
ideas and technologies. Simulations of past 
transportation events allow planners to better 
understand what really happened. By simulating 
future changes, decision makers can greatly 
improve the roadways of tomorrow. 

Alternatives are frequently proposed in different 
locations of cities for the future development of 
city and federal roadways. Proper testing of 
proposed plans must be done to assure best 
solution. One area of transportation system 
improvements that has largely not benefited from 
M&S testing is the installation or improvement of 
Intelligent Transportation Systems (ITS). 

IEEE’s Intelligent Transportation Systems Society 
defines ITS as systems that utilize synergistic 
technologies and systems engineering concepts 
to develop and improve transportation systems of 
all kinds. ITS refers to efforts to add information 
and communications technology to transport 
infrastructure. It strives to apply advanced 
technology to resolve the problems of surface 
transportation by improving efficiency, safety, and 
mobility. Other objectives include reducing 
energy, economic costs, and damage to the 
environment [2]. To better improve the planning 
of a large area such as the region of southeastern 
Virginia, ITS should be tested over the entire 
network to assess the improvements in traffic 
flows and congestion levels. This document will 
describe efforts and research to implement ITS 
and vehicle driver effects from ITS in a 
mesoscopic model using Avenue from the Cube 
family of transportation software. 


2. TECHNICAL BREAKDOWN OF CUBE 

2.1 Cube A Transportation Tool 

Cube family of transportation tools developed by 
Citilabs is chosen for this projects as the tool of 
choice because it is already selected as the 
planning standard by the Virginia Department of 
Transportation (VDOT). Cube provides a 
macroscopic transportation modeling tool, a 
microscopic modeling tool and a mesoscopic 
modeling tool, each of these tools can integrate 
together by sharing loaded networks. It also 
allows the modeler additional control with its 
scripting language allowing the ability to program 
in vehicle reactions that the software tool was not 
developed or intended to do through the default 
user interface. The scripting language is 
proprietary, and offers flexibility to make changes 
to road networks and Origin Destination matrices 
(OD). 

2.1.1 Microscopic Dynasim 

The Cube microscopic tool Dynasim is like other 
transportation micro simulation in that the user 
can simulate individual vehicle behavior creating a 
very accurate simulation. The problem with a 
micro simulation is the amount of time required to 
develop and run a scenario [4]. This problem 
usually requires the simulated area to be reduced 
to a more manageable size so that the simulation 
can run in a reasonable amount of time. 
Therefore, if the interest of the study is to see the 
effects of ITS on an intersection, a 
microsimulation would work quite well. This type 
of simulation will show you the local effects in a 
very small area very well, but what if the planners 
need to see effects in a larger scale in multiple 
locations at the same time? A microscopic 
simulation could accomplish this but require much 
more time to set up and to run. 
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2.1.2 Macroscopic Voyager 

The macroscopic tool within Cube, Voyager, is 
probably the most used and well known tool within 
the suite. Voyager can calculate volumes of traffic 
over large networks. It offers a number of 
modules that users can use to simulate 
transportation demand macroscopically. Each 
module requires its own input files, and using 
either a script file generated by the module to 
perform a default task, or a script created by the 
user to do a unique task can produce many 
outputs. Once the script runs the task the module 
can generate a number of outputs files of various 
formats that can be used as inputs to other 
modules or as strict outputs that visualize data. 

Voyager runs the highway module which 
produces the calculated values on each segment 
of the network for a period of time chosen by the 
user using a gravity model [1]. The highway 
module takes as in input a daily demand matrix, 
then uses the command pathload to run the 
volume over the network and using a gravity 
model to find an equilibrium over the network. 
The pathload command within highway takes a 
few inputs, one being the path variable. The path 
variable is used to set impedance over the 
roadways that are being simulated with pathload. 
The model developer can select different 
roadways to run with different pathload 

statements allowing multiple impedances over the 
entire road network. A typical example would be 
to see the average congestion for the Hampton 
Roads area for an entire day. In this case, the 
user could color code the road segments to 
display a range of colors representing the value of 
congestion. This type of output is useful for 
showing daily traffic and is able to highlight the 
roadways that are being overused. Using 

Voyager to model ITS is very possible and can 
show the change in volume on roads due to ITS in 
a static sense. However if the planner wants to 
simulate over time how vehicles are changing 
direction and routes, then the macroscopic model 
will not completely accomplish that. 



Figure 1: Shows an image of a Voyager output 
network with links color by level of service. 


2.1.3 Mesoscopic Avenue 

Mesoscopic models are in between a micro and a 
macroscopic model, allowing traffic volume to 
change over time through a large scale system 
[4]. While some mesoscopic simulation tools 
have more micro than macro features, Cube has 
more macro than micro features in that it 
simulates volume over the road network. 
Visualization of the output animation appears as a 
microscopic simulation where but it visualizes 
packets of vehicles based off of the volume 
calculations instead of individual vehicles. The 
mesoscopic tool in Cube is very closely related to 
the macroscopic tool, so close that it is actually 
just another module added to Voyager. 

Avenue is capable of reading in a list of OD 
matrices, one for each time segment and a 
network file. Time segments are defined time 
steps that the simulation advances and also are 
the defined moments when new volume can be 
added to the system by a new OD matrix. At each 
time segment the simulation will run the volume 
over the network as a discrete event simulation 
finding equilibrium then doing the same thing for 
the next time segment. All of this is done through 
Avenues Dynamicload statement. Much like the 
highway module’s pathload, Dynamicload uses a 
gravity model to calculate equilibrium, but instead 
of for one OD Matrix for one time period 
Dynamicload will calculate equilibrium for each 
time segment using the calculated equilibrium 
from the previous time segment. The output files 
that Avenue produces are matrix files, network 
files, data/text files, path files, packet log files and 
a few other types of outputs. The most important 
output file is the network file which contains 
values on all of the road segments from the last 
simulation run. Most of the values that are 
outputted on the road segments have a value for 
each time segment that the simulation ran. For 
example, volume, queue length, speed, and time 
are default outputs that Avenue provides, with 
each segment representing each variable as 
variable_t where t equals the time segment it 
represents and variable representing the name of 
the variable. This allows the user to color code 
the road segments over time using the Bandwidth 
chart display. A bandwidth chart is a display that 
gives the user controls to advance time and to see 
how that particular value changes. 
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Figure 2: Shows an output from one of the road 
segments in a simulation run providing values of 
Volume at each time segment. 
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Packet log output is a text file containing a record 
of locations where the packets have traveled for 
each time segment. The user can load this file 
over the network and view animations of the 
transportation that was simulated. The animation 
is a view of packets represented as rectangles 
over the loaded network. Users can control time 
to advance at different speeds and as time 
progresses the animation displays packets 
traveling the routes they were simulated to take 
towards their destinations. Since the packet log 
file is a text file, script files can be written with a 
matrix module to parse the log file and determine 
data that can be presented in a user created 
output file. An example of a parsing task would 
be to locate the amount of time segments it took 
each packet to arrive at its destination, and then 
average that value to obtain the average travel 
time for the simulation. 

Avenue’s dynamic assignment and flexibility along 
with its informative outputs and helpful 
visualizations make it a great choice for modeling 
vehicle behavior from ITS. Large areas can be 
simulated in a reasonable amount of time and in a 
time stepped simulation. Mesoscopic simulation 
benefits the non technical planners who need to 
understand how the simulated system is affected 
by driver behaviors. 

3. IMPLEMENTING A DAILY MESOSCOPIC 
MODEL 

3.1 A Hampton Roads Mesoscopic Model 

Implementing a daily mesoscopic model for a 
major metropolitan and especially in the Hampton 
Roads can be challenging. Demand must be 
generated for all origins and destinations at each 
time segment. This is typically done by taking 
percentages of the daily demand over each time 
segment. The problem with this technique in a 
Hampton Roads model is that the traffic patterns 
here resemble two peak load curve for most 
routes. One peak represents vehicles going one 
direction in the morning, and another representing 
the same traffic returning in the evening. The best 
solution will have demand values for the morning, 
lunch and evening traveling in the appropriate 
direction. Because the tests being done now are 
prototype tests, smaller percentages of the daily 
demand will work. 

3.2 Mesoscopic Model For Testing 

Specific tests require manually injecting traffic in a 
test area and applying congestion to one of the 
roadways in the way of this injected demand. 
This process is much like the process of doing a 
microscopic test in that only a small test area is 
being worked on. The demand is also set up 
much like the microscopic simulation where an 
origin destination matrix needs to be defined for 
each time segment. Once the test area is 
performing as expected the same type of driver 
intelligence can be applied in multiple areas for 


the entire Hampton Roads network, or in one spot 
with demand over the entire network to cause 
different reactions to the test area. 

4. CAUSING CONGESTION 

4.1 Implementing Incidents 

In order to realistically model driver behaviors and 
the influence of ITS, congestion must also be 
simulated. There are two ways that congestion 
can be accurately portrayed in Avenue. The 
easiest method is to overload the system with 
large amounts of vehicle traffic volume, a more 
realistic method involves injecting a simulated 
incident by reducing road capacity. The most 
precise way to create congestion where needed is 
to create an incident. Overloading the system 
with traffic volume is effective but can be 
unpredictable as traffic could overly congest areas 
that are not of interest. 

In Cube there is not a default function to apply 
incidents, so to implement incidents the modeler 
has to be able to use the Cube scripting language. 
The incidents modeled in Avenue require that the 
incident last as long as the time segment. A 
modeler cannot request Avenue to reduce the 
capacity of a roadway for one half of the time 
segment because all dynamic changes and 
calculations are done by time segment. Therefore 
to model fifteen minute incidents Avenue would 
require fifteen minute time segments or a different 
capacity reduction would need to be calculated. 
This new capacity would equal the capacity 
effects of a fifteen minute incident but at a one 
hour value [5]. The locations and severity of the 
incidents can be selected from historic data of 
road segments in Hampton Roads that are more 
likely to have an incident [5], or can be assigned 
to specific areas that a planner would like to 
study. 

The command Avenue uses to reduce capacity on 
road segments is Dynamic. The Dynamic 
command only works with the variable C. In 
Avenue to change the capacity of the road 
segment the C variable has to be changed which 
represents the capacity on the road segment over 
the entire simulated time. When the Dynamic 
command is used with C, a value of C is 
calculated for each time segment. The modeler 
can then alter the C value for any road segment at 
any defined time by using Dynamic and C. The 
script line needs to contain the A node (which 
refers to the starting point of a segment) and B 
node (which represents the end point of a 
segment) of the link segment, this is to assure that 
the incident occurs in the right direction and on 
the right road segment. The capacity is usually 
reduced by multiplying the current C variable by a 
reducing factor. When the time segment of the 
incident is over, the C variable is calculated by its 
normal calculation, capacity multiplied by lanes 
multiplied by simulation length. 
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IFQi.A = 66537 and ILB = 66791) 
DYNAMIC C[ 28] = li.C x 0.5 

The equation above shows a conditional 
statement that locates the link with an A node 
equal to 66537 and a B node equal to 66791 then 
sets its C variable to half of its normal value at 
time segment 28. 

5. SIMULATING DYNAMIC BEHAVIOR 

5.1 Road Impedance To Control Behavior 

Currently in Avenue dynamic behavior is already 
being simulated. The idea of this study is to better 
control that behavior and accurately simulate what 
is really happening. As stated in the 
documentation of Avenue, impedance for all road 
segments can be defined by the user. This 
impedance can be altered based on the road cost 
value, time to traverse link values, and user 
defined values. Smarter traffic can also be 
simulated by running multiple iterations of Avenue 
allowing the gravity model better equalize the 
network reducing congestion by having vehicles 
choose different routes based on the knowledge 
of the previous run simulation. This is accurate to 
a point, if an incident is being simulated then a 
multi iteration run is not going to be realistic. 
Therefore Avenue needs to be manipulated to 
allow the impedance of some specific roads to 
change at different times. 

When the evacuation model of the Hampton 
Roads was developed a compliance variable was 
implemented to control the behavior of vehicles 
sticking to the evacuation routes [5]. This same 
principal can be applied to this study. Early 
implementations involved using compliance 
variables over the network for each time segment. 
These compliance variables could then route 
vehicles around incident areas as if there were 
information alerting vehicles of these areas. 

The problem is that vehicles need to approach the 
accident segments as if knowledge of the accident 
doesn’t exist. Then once the accident knowledge 
can be distributed the vehicles need to make an 
attempt to divert. This clearly shows that the 
impedance needs to change dynamically. The 
only way to change the impedance is to change 
the path variable within Dynamicload. 

Dynamicload is Cube’s dynamic analog of the 
static PATHLOAD which is the heart of the 
macroscopic simulation, and takes as an input a 
list of volumes for each time segment as well as a 
path impedance (1). The path variable can be set 
to COST, TIME, or a list of working link variables 
(LW). LW variables can contain values of link 
impedance or impedance equations and can be 
set, then altered after each time segment in the 
ADJUST phase of Avenue. This provides a nice 
dynamic adjustment to the link impedance 
providing a more controlled environment to 
produce dynamic behavior in a simulated ITS 
event. 



Figure 3: Shows an Avenue output network with 
an incident occurring on a road segment indicated 
by the large red dot. 

5.1.1 Impedance set to Cost and Time 

By using a mixture of Cost and Time a simple and 
deterministic ITS system can be simulated. By 
using two Dynamicload statements ITS behavior 
can be achieved by using one statement for the 
time segments where ITS is being simulated and 
the other statement for normal times when ITS is 
not active or needed. This is accomplished by 
using Cost as the impedance for the Dynamicload 
simulating the ITS time segments and using Time 
as the impedance for the other Dynamicload 
statement to simulate impedance without ITS. 
This method also requires that your demand 
cooperates with the Dynamicload statements. For 
example during normal road impedance the 
regular demand matrices will be applied to the 
Dynamicload that has its path equal to Time, and 
during those time segments the other 
Dynamicload’s demand matrices should equal 
zero. When ITS effects need to be simulated then 
the Dynamicload with path equal to Cost takes the 
regular demand matrices and the Dynamicload 
with path equal to Time takes the zero demand 
matrices. This method keeps the regular volume 
flowing onto the network at all times and 
seamlessly simulates deterministic behavior due 
to ITS. 

5.1.2 Impedance set to LW variables 

Deterministic behavior really isn’t enough to 
simulate the true behavior of ITS effects so 
instead of using just Cost and Time as 
impedance, LW variables are used. LW variables 
for each time segment give the ability to simulate 
different behavior to the entire system. To 
simulate certain dynamic behaviors caused by 
ITS, specification of road segments to road 
impedance needs to take place. New variables 
can be assigned to the road network to give 
weighted values that can specify which roadways 
will be effected and which roadways will stay the 
same. By setting all normal roadways to a weight 
of 1 and the effected roadways to a value greater 
than one, a multiplicative operation to the 
impedance equation will result in a greater value 
for the effected road segments and a normal 
value for the non effected segment. 
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6. FUTURE WORK AND CONCLUSION 

Development and testing of these scenarios have 
a ways to go, but current tests show control over 
the traffic in a way that can be made more realistic 
to mimic real driver behaviors. Using driver 
survey’s to obtain data that can produce 
frequencies of when drivers decide to abandon a 
normal route because of information or congestion 
and to reroute either to a known or an unknown 
route. These frequencies can then be applied to 
the LW variable equations to create realistic 
simulations. Then using the data from the 
surveys the model can be validated to the number 
of vehicles that potentially would reroute. More 
tests of manipulating the LW values to be altered 
by time values per segment as well as congestion 
values are being done. Currently Avenue allows 
time to dynamically alter impedance variables but 
the results are inconsistent and need to be 
verified. 
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